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Overview 

This document describes the high-level approach taken to solving the problems related to when 
an expectation applies to a person, and when an expectation is considered due or over-due for 
the person. 

Definitions 

Expectation (EXP): Something that a health practitioner is expected to do with regard to a 
person being clinically evaluated. The expectation may be any number of things including, but 
not limited to, ordering a procedure, reviewing a health risk, educating the patient, or more. 

Qualification Facts: This is a small subset of information that will be used in the evaluation of 
the majority of rules. Right now we believe this subset with consists of the person's gender, age, 
problems, and diagnoses. In the future we will also expand this set to include clinical facts (as 
developed by the knowledge team). 

Satisfaction: A record of the fulfillment and completion of one or more action that satisfy a given 
expectation for a specific person. The possible actions include a broad range of types and events 
within the system. 

Start Up 

1. The service will create a cache for Qualification Facts during startup. This cache will be 
keyed by the Peronld and will include a structure that contains gender, birthdate, 
problems, and diagnosis. 

2. The service will read the following startup parameters and save them in static memory. 
These parameters will be used to determine when specific parts of the Qualification Facts 
must be reloaded from the database. 

a. GenderCacheExpirelnterval - Interval in seconds 

b. BirthdateCacheExpirelnterval - Interval in seconds 

c. ProblemCacheExpirelnterval - Interval in seconds 

d. DiagnosisCacheExpirelnterval - Interval in seconds 

3. The service will load all the reference data for the expectations. It will then compare this 
data with the current state of the data cached it in global memory. Any discrepancies in 
the data will be updated with the newest version of the data. Using this technique the 
cache will be automatically updated whenever any instance of the server is restarted. 

4. The service will start a worker thread used to retrieve and manage Qualification Facts. 

5. The service will start a worker thread used to... 

Service Requests 

1 . Get Qualified Expectations 



Person id 


Double 


Required 


Gender 


integer 


Optional 


Birthdate 


Date 


Optional 


Problems;] 


List 




Nomenclatureid 


Double 


Optional 


Diagnosis[] 


List 




Nomenciatureid 


Double 


Optional 


Facts[] 


List 




Nomenciatureid 


Doubie 


Future Use 



| The outpui message wiii bs a lis* of EXP thai the person qualiffes for. 
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Expectations!] 


List 




Expectationid 


Doubie 


Required 



a. If the optional parameters (Current Date/Time and Qualification Facts) are not 
supplied in the input message the service will retrieve the data. 

The Qualification Facte will be cached in memory for s pcedenned period of 
tine, Once they expire the cache will be released. The expiration Interval will 
he unique for each or" the following Qii.^jfjcatic-n Facts: Gender. Birth Date. 
probienvs : and Diagnoses. This expiration interval will he supplied as a startup 
props rty of the service 

The logic used to retrieve iha C^aiifiosiion Fads will ba implemented in a 
separate thread of execution, This Qualification Fact retrieval thread will run 
continuously waiting tor request to service. Once it finishes seivjomp, a 
reqnest Ir will pui the Oualllk:ation Facrs in ihe cache and will notify $§|||| 

b. Call Discern Expert passing it the full set of Qualification Facts including the 
gender, age (calculated from birth date), problems, and diagnoses. Base upon 
the result returned by Discern Expert we would either drop the EXP or keep it. 

II 'is assumes that a unique qualification rule will exist for each EXP §||§ 
Discern Expert Is designed to irlcgorthe execution of all rules ihat are 
associated with a given massage (request;, we can easily evaluate each 
qualification rule cy sanding a single message {request} to iha Discern expert 
server . This will he a new ruessace (request) I hat will he designed solely for 

via purpose of evaluating iha qualification or health expectations. Discern 
Expert will need to be reconfigured to recognize and aecepi this new message 

This new Input {request} message will Include the following; 



Person Id 


Double 


Required 


Gender 


Integer 


Required 


Age 


Double 


Required 


Problem.s[] 


List 




Nomenciatureld 


Doubie 


Required 


Diagnosis[] 


List 




Nomenciatureld 


Doubie 


Required 


Facts[] 


List 




Nomenciatureld 


Double 


Future Use 



Esch qualification rule will be responsible tor appendino its respective EXP to 
iha output {reply} message with an indicator that shows whether iha person 
qualifies or not.' 

The new output (reply} message win include the following. 



Expectations[] 


List 




Expectationid 


Doubie 


Required 


Qualifies 


Boolean 


Required 



I 



Health Expectstion > 
turn as qualified 


>ervic 


|| 


ill 


parse ti 


-re* 


-spiv 


tc 


CV 


*fen 


-sine v 




EXPS 



2. Get State of Expectations 



| ! he Input message will iii§||§| 



Person Id 


Double 


Required 


Expectations^ 


List 




Expectationid 


Doubie 


Required 


Evaluation DateTime 


Date/Time 


Ootional 



I The output message will include 1 the seme EXPs as the inpr.i1 message with the addition 
I of a status code and next due date flllllll 



Expectations!] 


List 




Expectationid 


Double 


Required 
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StatusCd 


Double 


Reauired 


Next Due 


Date/Time 


OdX io rial 



A predated list of ordcrabies. results and manually satisfied EXPs wiii be idemifiej||| 
data elements that Impact the Satisfaction History. 

For each EXP the foi tawing steps wit: nes|||§|||fin order to determine the co^p||||| 
history of pilar satisfactions 

a. Load the Satisfaction History from Orders 

For each igporryrniri thai is associated with the EXP. the persons orders wiii 
need to be evaluated, This will be accomplished ay reading the orders from 
the orders labia using a Key of Synonym id and Person id. 

R<r each order found the currant star; _dMm wiii be evaluated and coin pa red 
with other orders fa end for this EXP, The most recent current., start, dt.. tm wiii 
be considered the oaten Irr-e at wnfch this EXP was LAST satieties through the. 
placemen; of an aider 

b. Load the Satisfaction History from Results 

Mm each C Unci a! E ventCd that is associated with the EXP. the persons results 
will need to be evaluated. This win be accompiisheo: sy reading the results 
from the clinical event tabic using a key of CiinlcaiEveniCd and Person id. 

For each clinical event found the eonent.. start. dt..tm wiii be evaluated and 
compared with other clinical events found for this EXP The most recent 
cmrenTjsfart^ca Jm will be considered the date.'tiroe at which this £XP was 
LAST satisfied through the receipt of a cilnicai result. 



I For each EXP the tallowing steps wiii need to occur in order to determine the current 
state and next due dale of tne bXP. 

c. Evaluate each EXP by using the CDC algorithm. This evaluation will identify 
when the EXP is due again and whether it is currently overdue. 

The deiaiied specifications nor the CDC aiqontnm can ne round at 

Refer to the Expectation Evaluation 
Algorithm section nelcw for a corupiete description of the logic:. 

This algorithm requires the person s satisfaction history as input along with the 
current dale time. 

This algorithm also uses a set of reference data for each uXP being evaluated. 
Refer io the Expectation Satisfaction Parameter section below tor a complete 
description of this reference data. 

The EvaluationDataTime wiii be used if it is passed in the Input message if if 
is not included in the input message than the current date/ time wiii be used 

The satisfaction history wiii include ONLY trie cilnicai iosults as determine by 

■slie^DC algorithm writ be called for each EXP The result of this algorithm 
will be a status cede (Complete, Up.. To ..Date. No.. Recommended.. ' 
Comrolndicafed. Wrong. Aitemate or Recommended) The result may also 

Tigcllle; fhea-xaxt due data time it applicable 

vibe output message with Ce updated to Include the status and the next due 
3. Get Expectation Reminders 



| The input message wiii include- 



Remould 


Double 


Required 


Gender 


jnteger 


Optional 


Birthdate 


Date 


Optional 


Probiems[] 


List 




Nomenciatureid 


Double 


Optional 
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Diagnosis[] 


List 




Nomenciatureid 


Double 


Optionai 


Facts[] 


List 




Nomencialureld 


Doubie 


Future 
Use 



I The output message will bo a ik-i of EXPs that are not cuirently satisfied. Tor each EXP 
| the status cods and nev:f ci-i^ date will be included 



Expectations[] 


List 




Expectations 


Doubie 


Required 


StatusCd 


Doubie 


Required 


Next Due 


Date/Time 


Required 



a. Internally call the same logic as the "Get Qualified Expectations" request to 
determine what expectations this person qualifies for. 

This |$i simply forward the optionai parameters MMMMB Qualified,. 
Expects ions" request 

The result of this caii wiii bo a list of ~ *^;f^ P' € ^ : ' e w ^ ^ P ass<& ^ 

b. Internally call the same logic as the "Get State of Expectations" request. 



This will simply forward the op lion a I date time pa ram eta? and the iist of 


qualifying EXPs on to the 


'•Get Stale of Expectations''" re 


quest. 


The result will be a iist of 


~XPs with meiroonespoudiug 


status and next due 


date/lime. 







I Pot each EXP the following steps wiii need 10 ooour In order to reduce the iist of EXP 
sown to the ones thai are currently due or overdue. 

c. Drop all EXP that are already satisfied. 

Illllllte me status of the EXP. if the status indicates that the EXP as already 
satisfied then do not include ii in the outpui message. 

d. Drop all EXP that are not yet due. 

I! Evaiuaie the status of the EXP. if the status Indicates that the EXP Is noi yet 
due then do not include If in the output message 11111 

e. Include all remaining EXPs. 

IAii remainlno EXPs must be due or over due. Add each one to the output 
message along with the due dam and status. 



Service Requests Uses 

1 . Health Maintenance View. 

The "Get Expectation Reminders" request will be leveraged to get the expectations that 
are currently due or over-due. 

The person a gender and birth dote will oe mciuoed in the incut message, if the person's 
problems and'ot diagnoses have alteaciy been loaded then we will Include them In the 
input message. The current date-time wit; be included in the input message, 

2. Expectation Overdue Reports/Alerts. 

The "Get State of Expectations" request will be leveraged to determine whether a given 
person is due or over-due for a given EXP. 

I For each situation where a list of persons who are due or overdue for a given EXP is 
necessary this request will need to be called multiple times tonce foi each person). 
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it is assumsd mat tne list of persons who need to bw evaluated is known Often tin-as 
ih-s m wiH be a subset of the person population <e,g. Dr. Smith's pailento. Clinic A'a 
patient s) III 

Wo nro assuming that the avaloation will NEVER occur against She entire person 
population. 

Th<s ioc-iic necessary to retrieve the subs&l of person?, one- repsatediy sail the request is 
end car; easily he accomplished In COL, 



Expectation Satisfaction Parameters 

The following parameters have been identified from the CDC Algorithm as necessary attributes 
for accurate evaluation. Many of these parameters may be unnecessary for some EXPs and as 
such they are not all required for each EXP. 



Expectation Schedule 


Name 


String 


The name of the schedule 


Age of First Step 


Double 


The ... 


Expectation Series 


Name 


String 


The name of the series 


Age of First Step 


Double 


The ... 


Number of Steps 
Required 


Integer 


The number of steps required to complete this series. 


Unlimited Steps 


Boolean 


Indicates that the series include an unlimited number of steps. 


Expectation 


Name 


String 


The name of the expectation 


Interval Only 


Boolean 


Indicates that ... 


Sequence Number 


Integer 


The sequence at which the expectations will be recommended when 
more then one expectation is recommended. 


Minimum Age 


Double 


The minimum age at which this expectation is recommended. 


Maximum Age 


Double 


The maximum age at which this expectation is recommended. 


Expectation Step 


Step Number 


Integer 


The number of the step. 


Min. Interval to 
Count 


Long 


The interval (in days) between when the previous expectation step was 
satisfied and when this expectation step can count. 


Min. Interval to 
Administer 


Long 


The interval (in days) between when the previous expectation step was 
satisfied and when this expectation step can be safely administered. 


Recommended 
Interval 


Long 


The interval (in days) between when the previous expectation step was 
satisfied and when this expectation should be recommended. 


Minimum Age 


Double 


The minimum age at which this expectation step can be satisfied. 


Recommended Age 


Double 


The age at which this expectation step is recommended. 


Valid From Age 


Double 


The minimum age at which this expectation step should be 
recommended. 


Valid To Age 


Double 


The maximum age at which this expectation step should be 
recommended. 


Skip Age 


Double 


The age... 



Expectation Evaluation Algorithm 

The logic of this algorithm was obtained from the Center for Disease Control and Prevention 
National Immunization Program. This algorithm, although specifically developed for automating 
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the immunization evaluation process, can also be applied equally well to general health 
maintenance scenarios. It turns out that this algorithm more then satisfies the basic needs of 
most health maintenance guidelines. 

A detailed explanation of the algorithm logic and the recommended implementation approach can 
be found at http://www.cdc.gov/nip/registry/peg.pclf . 



